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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



£75/ 



3GPP TS 29.208 version 5.1 .0 Release 5 5 ETSI TS 1 29 208 V5.1 .0 (2002-09) 



Scope 



The present specification shows QoS signalHng flows for resource reservation to provide end-to-end QoS. The flows 
are used as bases of developing QoS related protocol descriptions for new and existing specifications. 

The relationship between SIP/SDP session level and the bearer level (RSVP and GPRS) in flows is described in 3GPP 
TS 24.228 [2]. The present specification adds detailed flows of service based local policy (SBLP) procedures over the 
Go interface and their relationship with the bearer level signalling flows over the Gn interface. 

The present specification also describes the mapping of QoS parameters among SDP, UMTS QoS parameters, and QoS 
authorization parameters. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 24.228: "Signalhng flows for the IP multimedia call control based on SIP and SDP; 

Stage 3". 

[3] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3". 

[4] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

[5] 3GPP TS 26.234: "End-to-end transparent streaming service; Protocols and codecs". 

[6] 3GPP TS 26.236: "Packet switched conversational multimedia applications; Transport protocols". 

[7] 3GPP TS 29.207: "Policy control over Go interface". 

[8] 3GPP TS 23.107: "Quality of Service (QoS) concept and architecture". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions as given in 3GPP TR 21.905 [1] apply. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply: 

COPS Common Open Policy Service protocol 

DEC COPS Decision message 

DRQ COPS Delete Request State message 

IMS IP Multimedia CN Subsystem 
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PCF 
REQ 
RPT 



Policy Control Function 
COPS Request message 
COPS Report State message 



4 Authorize QoS resources 

4.1 Authorize QoS resources at originating PCF 

This clause covers the Authorize QoS resources procedure at the originating PCF. 



UE 



GGSN 



SDP 



SDP 



P-CSCF 
PCF 



1. Define down-link 
connection info 



SDP 
SDP 



2. Define up-link 
connection info 



3. QoS autliorisation 



1 . The P-CSCF(PCF) gets the SDP parameters defined by the originator and identifies the connection 
information needed (IP address of the down link media flow, media ports to be used etc.). 

2. The P-CSCF(PCF) gets the negotiated SDP parameters from the terminating side through SIP signalling 
interaction. The P-CSCF{PCF) identifies the connection information needed (IP address of the up-link 
media flow, media ports to be used etc.). 

3. The P-CSCF(PCF) uses the SDP parameters in order to define the QoS resource authorisation. The PCF 
authorises every media component negotiated for the session. The authorization shall be expressed in 
terms of IP QoS parameters. An authorization token is generated by the PCF and sent to the UE. 

Figure 4.1 : Authorize QoS resources at originating PCF 
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4.2 Authorize QoS resources at terminating PCF 

This clause covers the Authorize QoS resources procedure at the terminating PCF. 



P-CSCF 
PCF 



SDR » 



GGSN 



1. Define up-link 
connection info 



2. Define down-linl< 
connection info 



QoS authorisation 



UE 



SDP 
SDP 



SDP 



The P-CSCF(PCF) gets the SDP parameters defined by the originator and identifies the connection 
information needed (IP address of the up-linl< media flow, media ports to be used etc.). An authorization 
token is generated by the PCF and sent to the UE. 

The P-CSCF(PCF) receives the negotiated SDP parameters from the UE. The P-CSCF(PCF) identifies the 
connection information needed (IP address of the down-link media flow, media ports to be used etc.). 
The P-CSCF(PCF) uses the SDP parameters in order to define the QoS resource authorisation. The PCF 
authorises every media component negotiated for the session. The authorization shall be expressed in 
terms of IP QoS parameters. 



Figure 4.2: Authorize QoS resources at terminating PCF 



5 Resource reservation flow with Service-based local 

policy 

This clause describes a resource reservation flow with service based local policy. The service based local policy is done 
via exchange of information through the Go interface. The Go interface allows the service based local policy and QoS 
interworking information to be requested by the GGSN from a PCF. 

The figure 5.1 presents the "Resource Reservation" procedure at PDP context activation to both the Mobile Originating 
(MO) side and Mobile Terminating (MT) side. 
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Figure 5.1 : Resource reservation flow with service based local policy 

1. Mapping from SDP to UMTS QoS parameters 

The UE uses the SDP parameters in order to define the UMTS QoS parameter needed to request a PDP context. The 
QoS parameter mapping mechanism is described in clause 7.2. 

2. GPRS: Activate PDP Context Request (UE to SGSN) 

The UE sends an Activate PDP Context Request message to the SGSN with the UMTS QoS parameters The UE shall 
include binding information in the PDP context activation messages to associate the PDP context bearer with policy 
information. The authorization token is sent by the P-CSCF to the UE during SIP signalling. 

3. GPRS: Create PDP Context Request (SGSN to GGSN) 

The SGSN carries out the procedures identified in 3GPP TS 23.060 [4] related to the PDP context activation. 

4. COPS: REQ (GGSN to PCF) 

The GGSN receives the PDP context activation request with the binding information. The GGSN uses the authorisation 
token in order to localise the PCF. The GGSN sends a COPS REQ message to the PCF and includes the binding 
information. 

5. Process Resource Request (PCF) 

The PCF receives the information sent by the GGSN. The PCF identifies the multimedia session by using the binding 
information. The PCF performs an authorization decision. 

6. COPS: DEC (PCF to GGSN) 

The decision taken by the PCF is returned via the COPS DEC message. The DEC message includes the policy 
information to be used by the GGSN in order to perform the policy-based admission control. 
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7. Policy Enforcement (GGSN) 

The GGSN enforces the PCF policy decision based on the received authorization information from the PCF for the 
media flows carried by the PDP context. 

8. COPS: RPT (GGSN to PCF) 

The GGSN sends COPS RPT message back to the PCF and reports its success or failure in carrying out the PCF 
decision. 

9. GPRS: Create PDP Context Response (GGSN to SGSN) 

The GGSN accepts the PDP context request based on the results of the authorisation policy decision enforcement. If the 
requested QoS parameters are not within the authorized QoS, the GGSN either rejects the PDP context activation 
request or downgrades the requested UMTS QoS parameters. 

10. GPRS: Activate PDP Context Accept (SGSN to UE) 

The SGSN sends an Activate PDP Context Accept message to the UE indicating that the PDP context has been 
activated and that the QoS requirements have been authorized successfully for both downlink and uplink. 



6 Other flows over Go interface 

6.1 Approval of QoS commit 

Through Approval of QoS Commit the PCF makes a final decision to enable the allocated QoS resource for the 
authorized media stream if the QoS resources are not enable at the time they are authorized by the PCF. 

The Approval of QoS Commit procedure is triggered by the P-CSCF receiving a 200 OK message. 

The following figure is applicable to the Mobile Originating (MO) side and the Mobile Terminating (MT) side. 
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GGSN 



P-CSCF 
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- 1.200 OK 



2. PCF approves 
the QoS Commit 



3. DEC 



4. GGSN opens the 
gate 



6. 200 OK 



5. RPT 



P-CSCF receives the 200 OK message. 

PCF approves the QoS Commit. 

PCF sends a COPS DEC message to the GGSN to open the 'gate' e.g., enable the use of the authorised 

QoS resources. 

GGSN receives the COPS DEC message and opens the 'gate' e.g., enables the use of the authorised 

QoS resources. 

GGSN sends a COPS RPT message back to the PCF. 

P-CSCF forwards the 200 OK message. 

Figure 6.1 : Approval of QoS Commit to both the Mobile Originating (MO) side 
and the Mobile Terminating (MT) side 



6.2 Removal of QoS commit 

The "Removal of QoS commit" procedure is used e.g. when a media component of a session is put on hold. (e.g. in case 
of a media re-negotiation or call hold). The PCF decision of "Removal of QoS commit " shall be sent as a separate 
decision to the GGSN corresponding to the previous "Authorize QoS Resources" request. 

6.2.1 Removal of QoS commit at Session on Hold 

The following figure presents the "Removal of QoS commit" procedure at session on hold to both the Mobile 
Originating (MO) side and the Mobile Terminating (MT) side. 
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GGSN 
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P-CSCF 
PCF 



LHold 



3. PCF removes the 

QoS Commit for 

the session 



4. DEC 



5. GGSN closes the 
related gates 



6. RPT 



1 . P-CSCF receives the Hold message. 

2. P-CSCF forwards the Hold message. 

3. PCF removes the QoS commit for the session. 

4. PCF sends a COPS DEC message to the GGSN to close the related 'gates'. 

5. GGSN receives the COPS DEC message, closes the 'gates'. 

6. GGSN sends a COPS RPT message back to the PCF. 

Figure 6.2.1 : Removal of QoS commit at Session on Hold to both the Mobile Originating (MO) side 

and the Mobile Terminating (MT) side 

6.2.2 Removal of QoS commit at Codec or media flow change or remove 

The following figure presents the "Removal of QoS commit" procedure at Codec or media flow change or remove to 
both the Mobile Originating (MO) side and the Mobile Terminating (MT) side. 
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1. 


3. PCF removes the 


QoS Commit for 
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Invite 



5. GGSN closes the 
related gate 



6. RPT 



1 . P-CSCF receives the INVITE message for codec or media change, remove. 

2. P-CSCF forwards the INVITE message. 

3. PCF removes the QoS commit for the related media flow. 

4. PCF sends a COPS DEC message to the GGSN to close the related 'gate'. 

5. GGSN receives the COPS DEC message, closes the 'gate'. 

6. GGSN sends a COPS RPT message back to the PCF. 

Figure 6.2.2: Removal of QoS commit at codec or media flow change 
or remove to both the Mobile Originating (MO) side and the Mobile Terminating (MT) side 



6.3 



Revoke authorization for GPRS and IP resources 



The "Revoke Authorization for GPRS and IP resources" procedure is used e.g. upon session release. The PCF decision 
of "Revoke Authorization for UMTS and IP Resources" shall be sent as a separate decision to the GGSN corresponding 
to the previous "Authorize QoS Resources" request. 

6.3.1 IVIobile initiated session release / Network initiated session release 

The following figure presents the "Revoke Authorization for UMTS and IP Resources" at upon Mobile initiated session 
release / Network initiated session release to both the Mobile Originating (MO) side and the Mobile Terminating (MT) 
side. 
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3. PCF removes the 
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5. GGSN disables 
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6. PDP context 
Deactivation 
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One mobile party hangs up or the P-CSCF or S-CSCF initiates BYE message. 

P-CSCF forwards the BYE message. 

PCF removes the authorisation for resources that had previously been issued for this endpoint for this 

session. 

PCF sends a COPS DEC message to the GGSN. It includes binding information, which identifies the PDP 

context to be deactivated. 

GGSN receives the COPS DEC message, and disables the use of the authorized QoS resources. 

GGSN initiates deactivation of the PDP context used for the IP multimedia session, in case the UE has not 

done it before. 

GGSN sends a COPS DRQ message back to the PCF. 

Figure 6.3.1 : Revoke authorization for GPRS and IP resources - 

Mobile initiated session release / Network initiated session release 

to both Mobile Originating (MO) and Mobile termination side 



6.4 



Indication of PDP Context Release 



The "Indication of PDP Context Release" procedure is used upon the release of a PDP Context that was established 
based on authorisation from the PCF in e.g. accidental/malicious removal of a PDP Context that is related to an IMS 

session. 

The following figure presents the "Indication of PDP Context Release" to both the Mobile Originating (MO) side and 
the Mobile Terminating (MT) side. 
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1 . SGSN deactivates the PDP context related to the media flow by sending the Delete PDP Context Request 
message to the GGSN. 

2. GGSN sends a COPS DRQ message to the P-GSGF(PGF). 

3. P-CSCF(PGF) receives the GOPS DRQ message and PGF may remove the authorization for the session. 

4. GGSN sends the Delete PDP Context Response message to the SGSN to acknowledge the PDP context 
deletion. 

NOTE: Step 4 may also occur at the same time or before Step 3. 

Figure 6.4.1 : Indication of PDP Context Release to both the Mobile Originating (IVIO) side 

and the lUlobile Terminating (IVIT) side 

The following figure presents the case when the GGSN initiates the release of a PDP context, i.e. after an error 
condition has been detected in GGSN. 



£75/ 



3GPP TS 29.208 version 5.1.0 Release 5 



15 



ETSI TS 129 208 V5.1.0 (2002-09) 



SGSN 



GGSN 



2. Delete PDP 
context request 



3. Delete PDP 
context response 
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1 . GGSN sends a COPS DRQ message to the P-CSCF(PCF). 

2. GGSN deactivates the PDP context related to the media flow(s) by sending the Delete PDP Context 
Request message to the SGSN. 

3. SGSN sends the Delete PDP Context Response message to the GGSN to acknowledge the PDP context 
deletion. 

4. P-CSCF(PCF) receives the COPS DRQ message and PCF may remove the authorization for the media 
flow(s) authorized for this PDP context. 

NOTE: Step 4 may also occur at the same time or before Step 2 and Step 3. 

Figure 6.4.2: Indication of GGSN-initiated PDP Context Release to both 
the Mobile Originating (MO) side and the Mobile Terminating (MT) side 



6.5 



Modification of PDP Context 



The "Modification of PDP Context" procedure is used when a PDP Context is modified such that the requested QoS 
falls outside of the limits that were authorized at PDP context activation (or last modification) or such that the 
maximum bit rate (downlink and uplink) is downgraded to kbit/s. In these cases, the GGSN communicates with the 
PCF as described below. 

6.5.1 Authorization of PDP Context IVIodification 

The figure 6.5.1 presents the "Modification of PDP Context" procedure to both the Mobile Originating (MO) side and 
the Mobile Terminating (MT) side when the UMTS QoS which were authorized at PDP context activation (or last 
modification) has been changed by UE. 
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1 . A request to modify the PDP context related to the media flow is indicated by sending the Update PDP 
Context Request message to the GGSN with the changed UMTS QoS parameters. 

2. If the GGSN supports a Local Policy Decision Point{LPDP), it can consult the local policy decision stored in 
the LPDP before sending the COPS REQ message to the PCF. In case the requested QoS is within the 
already authorized QoS and the binding information is not changed, the GGSN does not need to send an 
authorization request to the PCF and proceeds to step 5. Qtherwise, the GGSN sends a CQPS REQ 
message to the PCF. 

3. The PCF receives the CQPS REQ message and performs an authorization decision according to the 
requested modification. 

4. The decision taken by the PCF is returned via the CQPS DEC message. The DEC message includes the 
policy information to be used by the GGSN in order to perform the policy-based admission control. 

5. The GGSN enforces the policy decision based on the authorization information cached on the GGSN 
LPDP or received from the PCF for the media flows carried by the PDP context. 

6. The GGSN sends CQPS RPT message back to the PCF and reports its success or failure in carrying out 
the PCF decision and notifies state changes if any. 

7. The Update PDP Context Response message is sent to the SGSN to acknowledge the PDP context 
modification. 

Figure 6.5.1 : Authorization of PDP Context IVIodification to both the IVIobile Originating (IVIO) side 

and the IVIobile Terminating (MT) side 

6.5.2 Indication of PDP Context Modification 

The figure 6.5.2 presents the "Indication of PDP Context Modification" procedure to both the Mobile Originating (MO) 
side and the Mobile Terminating (MT) side when the maximum bit rate (downlink and uplink) for the PDP context is 
modified to and from kbit/s. 
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1 . SGSN modifies the PDP context related to the media flow{s) by sending the Update PDP Context Request 
message to the GGSN. 

2. GGSN sends a COPS RPT message to the PCF notifying the PDP context modification. 

3. PCF receives the COPS RPT message and forwards the indication to the P-CSCF. 

4. GGSN sends the Update PDP Context Response message to the SGSN to acknowledge the PDP context 
modification. 

NOTE: Step 4 may also occur at the same time or before Step 3. 

Figure 6.5.2: Indication of PDP Context Modification to both the Mobile Originating (MO) side 

and the Mobile Terminating (MT) side 



7 QoS parameter mapping 

7.1 QoS parameter mapping between IIVIS and GPRS 

Within the IM sub-system, session estabHshment and modification involves an end-to-end message-exchange using 
SIP/SDP with negotiation of media attributes (e.g. Codecs) as defined in 3GPP TS 24.229 [3] and 3GPP TS 24.228 [2]. 
The P-CSCF shall forward the relevant SDP information to the PCF together with an indication of the originator. The 
PCF notes and authorises the chosen media components and their attributes by mapping from SDP parameters to 
Authorized IP QoS parameters for transfer to the GGSN via the Go interface. The GGSN will map from the Authorized 
IP QoS parameters to the Authorized UMTS QoS parameters. The SIP/SDP message will also have been passed on to 
the UE, where the UE will perform its own mapping from the SDP parameters and application demands to some UMTS 
QoS Parameters in order to populate the requested QoS field within the PDP context activation or modification. If the 
SDP parameters are received in an IMS context the UE should take the mapping from the SDP parameters to the 
Authorized UMTS QoS parameters into consideration. If the UE contains an IP BS manager IP QoS parameters are also 
generated. Upon receiving the PDP context activation or modification, the GGSN shall compare the UMTS QoS 
parameters against the Authorized UMTS QoS parameters. If the request lies within the limits authorised by the PCF, 
the PDP context activation or modification shall be accepted. 

Figure 7.1 indicates the network entities where QoS mapping functionality is required. This mapping is performed by: 

1 . The PCF maps from the SDP parameters determined from the SIP signalling to the Authorized IP QoS 
parameters that shall be passed to the GGSN via the Go interface. The mapping is performed for each IP flow of 
each media component. Upon a request from the GGSN, the PCF combines per direction the individual 
Authorised IP QoS parameters of the IP flows that are identified by the binding information (see clause 7.1.1). 

2. The UE maps from the SDP parameters to IP QoS parameters (if an IP BS manager is present) and to UMTS 
QoS parameters. This mapping is performed for each IP flow of each media component. The IP and UMTS QoS 
parameters should be generated according to application demands and recommendations for conversational [6] 
or streaming applications [5] (see clause 7.2.1). The mapping rules for the authorised QoS parameters should be 
taken into consideration because they define the maximum values for the different requested bit rates and traffic 
classes (see clause 7.2.2). In case the UE multiplexes several IP flows onto the same PDP context, it has to 
combine their IP and UMTS QoS parameters. If an IP BS manager is present, the Translation/Mapping function 
maps the IP QoS parameters to the corresponding UMTS QoS parameters. 
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3 The GGSN maps from the Authorized IP QoS parameters received from PCF to the Authorized UMTS QoS 

parameters (see clause 7.1.2). 

4 The GGSN compares then the UMTS QoS parameters of the PDP context against the Authorized UMTS QoS 
parameters (see clause 7.1.3). 

The mapping that takes place in the UE and the network shall be compatible in order to ensure that the GGSN will be 
able to correctly authorise the session. 
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NOTES 
NOTE 4 



SDP parameters to Authorized IP QoS parameters mapping. 
SDP parameters to (IP QoS parameters and) UMTS QoS parameters mapping. 
Authorized IP QoS parameters to Authorized UMTS QoS parameters mapping. 
UMTS QoS parameters with Authorized UMTS QoS parameters comparison. 

Figure 7.1 : Framework for QoS mapping between IIVIS and GPRS 

SDP parameters to Authorized IP QoS parameters mapping in PCF 

The QoS authorization is to be based on the parameters Maximum Authorized DiffServ PHB and Maximum Authorized 
Data Rate UL/DL. 

The PCF shall use the mapping rules in table 7.1.1.1 to derive the Authorized IP QoS parameters Maximum Authorized 
Data Rate DL/UL and the Maximum Authorized DiffServ PHB from the SDP Parameters. In case of forking, the 
additional rule in section 7.3 shall apply. 



7.1.1 
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Table 7.1.1.1 : Rules for derivation of the lUlaximum Authorized Data Rates 
and IVIaximum Authorized DiffServ PHB per media flow in the PCF 



Authorized IP 
QoS Parameter 
per media flow 



Derivation from SDP Parameters 



Maximum 
Authorized Data 
Rate DL 
(l\/lax_DR_DL) 
andUL 
(l\/lax_DR_UL) 
per media flow 
(see note 1) 



IF a=recvonly THEN 

IF <SDP direction> = mobile originated THEN 

Direction:= downlink; 
ELSE /* mobile teminated 7 

Direction;= uplink; 
ENDIF; 
ELSE 

IF a=sendonly THEN 

IF <SDP direction> = mobile originated THEN 

Direction: = uplink; 
ELSE /* mobile teminated 7 

Direction:= downlink; 
ENDIF; 
ELSE Tsendrecv or no direction attribute7 

Direction:=both; 
ENDIF; 
ENDIF; 

IF b=AS:<bandwidth> is present THEN 
IF Direction=downlink THEN 

IF <transport>="RTP/AVP" then 

Max_DR_UL:=0.025 * <bandwidth>; 
Max_DR_DL:=1 .025 * <bandwidth>; 
ELSE 

Max_DR_UL:=0; 
IVlax_DR_DL:=<bandwidth>; 
ENDIF; 
ELSE 

IF Direction=uplinkTHEN 

IF <transport>="RTP/AVP" then 

Max_DR_UL:= 1.025 * <bandwidth>; 
IVIax_DR_DL:=0.025 * <bandwidth>; 
ELSE 

Max_DR_UL:=<bandwidth>; 
Max_DR_DL:=0; 
ENDIF; 
ELSE /*Direction=both7 

Max_DR_UL:= 1 .025 * <bandwidth>; 
Max_DR_DL:= 1.025 * <bandwidth>; 
ENDIF; 
ENDIF; 
ELSE 

bw:= as set by the operator; 
IF Direction=downlink THEN 
l\/lax_DR_UL:=0; 
Max_DR_DL:=bw; 
ELSE 

IF Direction=uplink THEN 
IVIax_DR_UL:=bw; 
Max_DR_DL:=0; 
ELSE /*Direction=both7 
IVIax_DR_UL:=bw; 
Max_DR_DL:=bw; 
ENDIF; 
ENDIF; 
ENDIF; 
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Maximum 
Authorized 
DiffServ PHB 
[MaxClass] per 
media flow 
(see note 2) 


CASE <media> OF 

"audio": MaxClass:=EF; 
"video": MaxClass:=EF; 
"application": MaxClass:=EF; 
"data": MaxClass:=AF1 
"control": MaxClass:=AF3 


/'conversational*/ 
/'conversational*/ 
/'conversational*/ 
/'interactive with priority 3*/ 
/*interactive with priority 1'/ 




/'new media type'/ 
OTHERWISE: MaxClass:=BE; 
END; 


/'background'/ 


NOTE 1 : For a RTP media flow the Maximum Authorized Bandwidth DL/UL are the sum of the RTP flow DL/UL and 

the associated RTCP flow DL/UL. 
NOTE 2: The Maximum Authorized Traffic Class for a RTCP flow is the same as the corresponding RTP flow. 



Editor's note: Further clarification is required if the SDP b=AS:<bandwidth> parameter includes the bandwidth 
for RTCP. 

The PCF shall per ongoing session store the Authorized IP QoS parameters per media flow. 

When the GGSN requests the Authorized UMTS QoS parameters for an activated/modified PDP Context carrying one 
or more media flows (eventually with associated RTCP signalling), the PCF shall use the rules in table 7.1.1.2 to 
calculate the Authorized IP QoS parameters. 

Table 7.1.1.2: Rules for calculating the Maximum Authorized Data Rate 
and Maximum Authorized Diffserv PHB Parameters per Binding Information in the PCF 



Authorized IP 

QoS Parameter 

per Binding 


Calculation Rule 


Maximum 
Authorized Data 
Rate DL and UL 
per Binding 
Information 


Maximum Authorized Data Rate DL/UL per Binding Information is the sum of all Maximum 
Authorized Data Rate DL/UL per media flow for all the media flows identified by the Binding 
Information 

IF Maximum Authorized Data Rate DL/UL per Binding Information > 2047 kbps THEN 

Maximum Authorized Data Rate DL/UL per Binding Information = 2047 kbps /* See ref [8] */ 

END; 


Maximum 
Authorized 
Diffserv PHB per 
Binding 
Information 


Maximum Authorized Diffserv PHB per Binding Information = MAX [Maximum Authorized Diffserv 
PHB per media flow among all the media flows identified by the Binding Information 

(The MAX function ranks the possible Maximum Authorized Diffserv PHB values as follows: "EF" 
> "AF4" > "AF3" > "BE") 



7.1 .2 Authorized IP QoS parameters to Authorized UMTS QoS 
parameters mapping in GGSN 

The Translation/Mapping function in the GGSN shall derive the Authorized UMTS QoS parameters from the 
Authorized IP QoS parameters received from the PCF according to the rules in table 7.1.2. 
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Table 7.1.2: Rules for derivation of the Authorized UIUITS QoS Parameters 
from the Authorized IP QoS Parameters 



Authorized 
UMTS QoS 
Parameter 



Derivation from Authorized IP QoS Parameters 



Maximum 
Authorized 
Bandwidth DL 
andUL 



Maximum Authorized Bandwidth DL/UL = IVIaximum Authorized Data Rate DL/UL 



Maximum 
Authorized 
Traffic Class 



IF IVIaximum Authorized Diffserv PHB = "EF" THEN 
Maximum Authorized Traffic Class = "Conversational" 

ELSEIF Maximum Authorized Diffserv PHB = "AF4" THEN 
Maximum Authorized Traffic Class = "Streaming" 

ELSEIF Maximum Authorized Diffserv PHB = "AF3" THEN 
Maximum Authorized Traffic Class = "Interactive" 

ELSE Maximum Authorized Traffic Class = "Background" 
ENDIF; 



7.1 .3 Comparing UMTS QoS Parameters against tlie Autinorized UMTS 
QoS parameters in GGSN 

Upon receiving a PDP context activation containing binding information, the GGSN requests the Authorized QoS 
information from the PCF, and might request the Authorized UMTS information if a PDP context containing binding 
information is modified (see [7] for details). The GGSN compares the requested UMTS QoS parameters against the 
corresponding Authorized UMTS QoS parameters received via the translation/mapping function. If all the requested 
parameters lie within the limits, the PDP context activation or modification shall be accepted. I.e. the following criteria 
shall be fulfilled: 

• the requested Guaranteed Bitrate DL/UL (if the requested Traffic Class is Conversational or Streaming) or 
Maximum Bitrate DL/UL (if the requested Traffic Class is Interactive or Background) is less than or equal to 
Maximum Authorized data rate DL/UL and 

• the requested Traffic Class is less than or equal to Maximum Authorized Traffic Class. 

If any of the requested parameters do not lie within their respective limit, the GGSN shall downgrade the requested 
UMTS QoS parameters. 

7.2 QoS parameter mapping in the UE 

Figure 7.2 indicates the entities participating in the generation of the requested QoS parameters when activate or modify 
a PDP Context in the UE. The steps are: 

1. The Application provides the UMTS BS Manager, possibly via the IP BS Manager and the Translation/Mapping 
function, with relevant information to perform step 2 or step 4. (Not subject to standardization within 3GPP). 

2. If needed, information from step 1 is used to access a proper set of UMTS QoS Parameters. See 3GPP TS 26.236 
[6] for Conversational Codec Applications and 3GPP TS 26.234 [5] for Streaming Codec Applications. 

3. If SDP is present then the SDP Parameters might give guidance for the UMTS BS Manager to set the Maximum 
Bitrate UL/DL, Guaranteed Bitrate UL/DL and the Maximum SDU Size. The Application deliver extracted SDP 
information, possibly via the IP BS Manager, to the Translation/Mapping function. The Translation/Mapping 
function finally derives the UMTS QoS parameters according to the rules in clause 7.2.1. Furthermore if the SDP 
Parameters are received in an IMS context it is recommended that the Maximum Authorized Bandwidth UL and 
DL and Maximum Authorised Traffic Class are derived according to the rules in clause 7.2.2. 

4. A set of UMTS QoS Parameters values from step 2 (or directly from step 1) is eventually merged together with 
the Maximum Bitrate UL/DL, the Guaranteed Bitrate UL/DL and the Maximum SDU Size from step 3. The 
result constitutes a recommendation of requested UMTS QoS Parameters. If the PDP Context is activated or 
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modified in an IMS context it is recommended that the UE checks that the actual requested Guaranteed Bitrate 
UL/DL or requested Maximum Bitrate UL/DL (depending on the requested Traffic Class) are not greater than 
the Maximum Authorized Bandwidth UL/DL derived in step 3. Furthermore, if the UE has implemented the 
mapping rule for Maximum Authorized Traffic Class, as defined in clause 7.2.2, it is also recommended that the 
requested Traffic Class is not greater than the Maximum Authorised Traffic Class derived in step 3. 
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Figure 7.2: Framework for generating requested QoS parameters in the UE 

7.2.1 SDP to UMTS QoS parameter mapping in UE 

If SDP Parameters are available, then before activating or modifying a PDP Context the UE should check if the SDP 
Parameters give guidance for setting the requested UMTS QoS Parameters. The UE is recommended to use the 
mapping rules in table 7.2.1 to derive the Maximum and Guaranteed Bitrate DL/UL and Maximum SDU Size from the 
SDP Parameters. 
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Table 7.2.1 : Recommended rules for derivation of the requested IVIaximum 
and Guaranteed Bitrate DL/UL and the requested IVIaximum SDU Size in the UE 



UMTS QoS Parameter 


Derivation from SDP Parameters 


Maximum Bitrate DL/UL 

and 

Guaranteed Bitrate 

DL/UL 


/* Check if the media use codec{s) 7 

IF [(<media> = ("audio" or "video")) and (<transport> = "RTP/AVP")] THEN 

/* Check if Streaming 7 

IF a= ("sendonly" or "recvonly") THEN 

IVIaximum Bitrate DL/UL and Guaranteed Bitrate DL/UL as specified in reference 
[5]; 
/* Conversational as default 17 
ELSE 

Maximum Bitrate DL/UL and Guaranteed Bitrate DL/UL as specified in reference 
[6]; 
ENDIF; 

/* Check for presence of bandwidth attribute 7 
ELSEIF b=AS:<bandwidth-value> is present THEN 

IVIaximum Bitrate DL/UL and Guaranteed Bitrate DL/UL = "bandwidth-value" ; 
ELSE 

/* SDP do not give any guidance ! 7 

Maximum Bitrate DL/UL and Guaranteed Bitrate DL/UL as specified by the UE 

manufacturer; 

ENDIF; 


Maximum SDU size 


/* Check if the media use codec(s) 7 

IF [(<media> = ("audio" or "video")) and (<transport> = "RTP/AVP")] THEN 

/* Check if Streaming 7 

IF a= ("sendonly" or "recvonly") THEN 

Maximum SDU Size as specified in reference [5] ; 

/* Conversational as default 17 
ELSE 

Maximum SDU Size as specified in reference [6] ; 
ENDIF; 

ELSE 

Maximum SDU Size as specified by the UE manufacturer ; 

ENDIF; 



7.2.2 SDP parameters to Authorized UMTS QoS parameters mapping in 
UE 

If the PDP Context is activated or modified in an IMS context then it is recommended that the UE uses the mapping 
rules in table 7.2.2.1 to derive the Maximum Authorized Bandwidth UL/DL. 

Table 7.2.2.1 also has a mapping rule for derivation of Maximum Authorized Traffic Class. In future releases this 
mapping rule may change. For the reason of future compatibility, the release 5 mapping rule is optional for the UE. 

In the case this mapping rule is implemented then it is recommended that the UE use the mapping rule in table 7.2.2. 1 to 
derive the Maximum Authorised Traffic Class from the SDP Parameters. 

When the maximum authorized QoS for a media flow in forked responses is derived, the additional rule in section 7.3 
shall apply. 
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Table 7.2.2.1 : Rules for derivation of the Maximum Authorized Bandwidth DL/UL 
and the Maximum Authorized Traffic Class per media flow in the UE 



Authorized UIVITS QoS 

Parameter per media 

flow 



Derivation from SDP Parameters 
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Maximum Authorized 
Bandwidth DL 
(Max_BW_DL) and UL 
(Max_BW_UL) per media 
flow 



/* Check if IMS context (the criteria for this check is an UE manufactures issue ) 7 
IF IIVIS context THEN 

IF a=recvonly THEN 

IF <SDP direction> = mobile originated THEN 

Direction:= downlink; 
ELSE /* mobile teminated 7 

Direction:= uplink; 
ENDIF; 
ELSE; 

IF a=sendonly THEN 

IF <SDP direction> = mobile originated THEN 

Direction: = uplink; 
ELSE /* mobile teminated 7 

Direction:= downlink; 
ENDIF; 
ELSE Tsendrecv or no direction attribute7 

Direction:=both; 
ENDIF; 
ENDIF; 

IF b=AS:<bandwidth> is present THEN 
IF Direction=downlink THEN 

IF <transport>="RTP/AVP" then 

IVIax_BW_UL:=0.025 * <bandwidth>; 
IVIax_BW_DL:=1 .025 * <bandwidth>; 
ELSE 

IVIax_BW_UL:=0; 
Max_BW_DL:=<bandwidth>; 
ENDIF; 
ELSE 

IF Direction=uplinkTHEN 

IF <transport>="RTP/AVP" then 

IVIax_BW_UL:= 1.025 * <bandwidth>; 
IVIax_BW_DL:=0.025 * <bandwidth>; 
ELSE 

IVIax_BW_U L:=<bandwidth> ; 
IVIax_BW_DL:=0; 
ENDIF; 
ELSE /*Direction=both7 

Max_BW_UL:= 1 .025 * <bandwidth>; 
Max_BW_DL:= 1 .025 * <bandwidth>; 
ENDIF; 
ENDIF; 
ELSE 

bw:= as set by the UE manufacturer; 
IF Direction=downlink THEN 
Max_BW_UL:=0; 
Max_BW_DL:= bw; 
ELSE 

IF Direction=uplinkTHEN 
IVIax_BW_UL:= bw; 
Max_BW_DL:=0; 
ELSE /*Direction=both7 
IVIax_BW_UL:= bw; 
Max_BW_DL:= bw; 
ENDIF; 
ENDIF; 
ENDIF; 



ELSE 

No authorization is done 
ENDIF; 
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Maximum Authorized 


/* Check if IMS context (the criteria for this check is an UE manufactures issue 


7 


Traffic Class 


IF IMS context THEN 




[MaxTrafficClass] per 


CASE <media> OF 




media flow 


"audio": MaxTrafficClass:=conversational; 
"video": MaxTrafficClass:=conversational; 
"application": MaxTrafficClass:=conversational; 
"data": MaxTrafficClass:=interactive with priority 3; 
"control": MaxTrafficClass:=interactive with priority 1 ; 

/*new media type*/ 

OTHERWISE:MaxTrafficClass:=background; 
END; 
ELSE 

No authorization is done ; 
ENDIF; 





Editor's note: Further clarification is required if the SDP b=AS:<bandwidth> parameter includes the bandwidth 
for RTCP. 

It is recommended that the UE per ongoing session store the Authorized UMTS QoS parameters per media flow. 

Furthermore it is recommended that the UE checks that the requested UMTS QoS parameters Traffic Class and 
Maximum Bitrate UL/DL not exceeds the values of the corresponding Authorized UMTS QoS parameters (calculated 
according to the rules in table 7.2.2.2) before activating/modifying a PDP Context. See section 7.1.3 for recommended 
criteria to be fulfilled. 

The table 7.2.2.1 defines mapping rules to determine the Maximum Authorized Traffic Class. This table does not 
specify how to determine the UMTS QoS parameter traffic class. 

Table 7.2.2.2: Rules for calculating the Maximum Authorized Bandwidths 
and Maximum Authorized Traffic Class Parameters per PDP Context in the UE 



Authorized 

UMTS QoS 

Parameter per 

PDP Context 


Calculation Rule 


Maximum 
Authorized 
Bandwidth DL 
and UL per PDP 
Context 


/* Check if IMS context (the criteria for this check is an UE manufactures issue ) 7 
IF IMS context THEN 

Maximum Authorized Bandwidth DULIL per PDP Context is the sum of all Maximum 
Authorized Bandwidth DL/UL per media flow for all the media flows to be carried by the PDP 
Context ; 

IF Maximum Authorized Bandwidth DL/UL per PDP Context > 2047 kbps THEN 

Maximum Authorized Bandwidth DL/UL per PDP Context = 2047 kbps /* See ret [8] 7 
END; 

ELSE 

No authorization is done ; 
ENDIF; 


Maximum 
Authorized 
Traffic Class per 
PDP Context 


/* Check if IMS context (the criteria for this check is an UE manufactures issue ) 7 
IF IMS context THEN 

Maximum Authorised Traffic Class per PDP Context = MAX [Maximum Authorised Traffic 
Class per media flow among all the media flows to be carried by the PDP Context] ; 

ELSE 

No authorization is done ; 
ENDIF; 

(The MAX function ranks the possible Maximum Authorised Traffic Class values as follows: 
Conversational > Streaming > Interactive > Background) 
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7.3 Support for forking 



For an initiated session the UE and the PCF may receive several forked responses, ref. 3GPP TS 29.207 [7]. The 
various forked responses may have different QoS requirements for the same media flow. In the case of forked 
responses, the maximum authorized QoS for a media flow shall be equal to the highest QoS requested for that media 
flow by any of the active forked responses. This applies both to the UE and to the PCF. 
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